home *** CD-ROM | disk | FTP | other *** search
/ Monster Media 1996 #15 / Monster Media Number 15 (Monster Media)(July 1996).ISO / internet / ipad0002.zip / IPAD0002.TXT
Text File  |  1996-05-21  |  10KB  |  236 lines
  1. IPAD 1.1 - DNS Troubleshooting
  2.  
  3. Contact:   eSoft, Inc. (Makers of TBBS)
  4.        15200 E. Girard Ave., Suite 3000
  5.        Aurora, CO  80014
  6.        (303) 699-6565      Voice
  7.        (303) 699-6872      Fax
  8.        (303) 699-8222      BBS
  9.        support@esoft.com   E-Mail
  10.  
  11. -----------------------------------------------------------------------------
  12. IPAD Tech Note #2       DNS Issues                                     3/14/96
  13.  
  14. INTRODUCTION
  15. ============
  16.  
  17.         The purpose of this tech note is to explain in greater detail
  18. the relationship between the DNS server and resolver as well as tools
  19. you might use to diagnose common problems.
  20.  
  21. THE DNS SERVER AND RESOLVER
  22. ===========================
  23.  
  24.         DNS, the Domain Name System, works using a server and a resolver.
  25. The server contains information and can find out information it doesn't
  26. know from other servers.  The resolver is the user-end client that queries
  27. a server for specific information.
  28.  
  29.         Since domain names are meaningless to TCP/IP, DNS is used to map these
  30. names to IP addresses.  In this way, the Internet is "humanized" so that people
  31. don't need to remember meaningless IP addresses such as 199.45.145.5, and
  32. can instead remember an organized name like www.esoft.com.  When a user
  33. enters www.esoft.com into their web browser, the resolver is the part that
  34. first takes over to help determine the corresponding IP address.  The
  35. resolver "talks" to a known DNS server and says "Who is www.esoft.com?"
  36.  
  37.         Once the DNS server receives the resolver's query, it proceeds to
  38. ask other servers where it needs to go.  First, it will look in it's cache,
  39. which is a collection of the most recently requested domain names.  If the
  40. name can't be found there, the server will ask a root server for the
  41. information.  While a root server won't tell the IP address for www.esoft.com,
  42. it can tell the server requesting that information to go to eSoft's DNS
  43. server at 199.45.143.14 to find out.  When the DNS server connects to
  44. eSoft's name server, it will be told that www.esoft.com maps to the IP
  45. address 199.45.143.5.  The DNS server will write this information to its
  46. cache (incase it's asked again) and will send a message back to the user's
  47. resolver, letting it know the correct IP address.
  48.  
  49.         Once the resolver has the IP address, it can pass it onto the
  50. web browser application, so the browser can make the desired HTTP connection.
  51.  
  52. COMMON PROBLEMS
  53. ===============
  54.  
  55.         Now that you understand the relationship between the DNS server
  56. and resolver, there are a few problems which can arise.  Typically a user
  57. will be notified "DNS name could not be found!" or "Could not access
  58. www.esoft.com!"  Since the application relays this message, it can appear
  59. inconsistent among different applications while there can be different
  60. explanations for the problem.
  61.  
  62. Resolver Timeout
  63. ----------------
  64.  
  65.         The relationship between a DNS resolver and server are not really
  66. a transaction in the sense that you might think it to be.  That is, the
  67. familiar "pause" you experience when typing a domain name in at a
  68. web browser or telnet prompt is NOT the resolver connecting to the server
  69. and waiting for a response.  Instead, the resolver sends its message to
  70. the server and waits for the server to send its message.
  71.  
  72.         When the resolver's timer expires, it will report back to the
  73. application that the domain name's IP address couldn't be found.  HOWEVER,
  74. since it's the server's responsibility to notify the resolver that it
  75. can or can't find the information, a very real possibility is that the
  76. server is STILL looking for the DNS information when the resolver times
  77. out and tells the application that it doesn't know what the IP address is.
  78. While many resolvers time out after 15 seconds, depending on the situation on
  79. the Internet, it can take a server longer to find that information, sometimes
  80. up to 30 or 45 seconds.  In fact, if you re-load the domain name afterwards,
  81. chances are good that the server will have the information and return it to
  82. the resolver from its cache.
  83.  
  84.         As a result, the whole process of finding a domain name from the
  85. perspective of resolver-server interaction is akin to a deaf child knocking
  86. on the front door.  The child, or resolver, will knock three times, and if the
  87. door doesn't open, it will walk away.  It won't be able to hear the person
  88. inside shouting "Hey, I'm working on it!" to stick around.
  89.  
  90.         You can see this problem in action if you perform a lookup on a name,
  91. receive a timeout, and look at the DNS cache.  For example, if you performed
  92. a recursive lookup using the IPAD's NSlookup command:
  93.  
  94.  Cmd> nslookup -rec esoft.com
  95.  
  96. (the -rec means that the specified or, as in this case, assumed DNS server
  97. should do the looking - not the nslookup program)
  98.  
  99. and received the following:
  100.  
  101.  Non-authoritative response:
  102.  
  103.  Server reported No type "ANY" RR records for esoft.com.
  104.  
  105.  Server address          srtt    mdev   timeout   queries responses  timeouts
  106.  199.45.143.14           1543       0      5000         3         0         3
  107.  
  108.         This means that the nslookup, acting as a resolver, queried the
  109. name server at 199.45.143.14 three times and didn't receive a response.
  110. However, it might mean that it took longer for the server to find that
  111. information.  If you looked at the memory portion of the DNS cache using
  112. the command:
  113.  
  114.  Cmd> domain cache list
  115.  
  116.         You would see information for esoft.com placed at the top of the
  117. list.  If you issued the same nslookup command again, you would receive
  118. the information for esoft.com.
  119.  
  120.  
  121. Sever can't be reached
  122. ----------------------
  123.  
  124.         Another problem can be that an authoritative name server for the
  125. domain name cannot be reached.  This is typically due to a downed route or
  126. name server machine.  Your server can't reach the site so it has no choice
  127. but to tell the resolver that it can't find the domain name.
  128.  
  129.         To see if this is the case perform a traceroute to the name server.
  130. First, find out the domain name or IP address for the name server that is
  131. authoritative for the domain you're looking for.  Do this by asking a
  132. root server, such as in the following example:
  133.  
  134.  Cmd> nslookup esoft.com a.root-servers.net
  135.  
  136.         You would receive the following information:
  137.  
  138.  Non-authoritative response:
  139.  
  140.  esoft.com.      172800  IN      NS      NS1.esoft.com.
  141.  esoft.com.      172800  IN      NS      NS2.esoft.com.
  142.  
  143.  Authority resource records:
  144.  esoft.com.      172800  IN      NS      NS1.esoft.com.
  145.  esoft.com.      172800  IN      NS      NS2.esoft.com.
  146.  
  147.  Additional information resource records:
  148.  NS1.esoft.com.  172800  IN      A       199.45.143.14
  149.  NS2.esoft.com.  172800  IN      A       199.45.143.150
  150.  
  151.         From this information, you can see that the name servers
  152. ns1.esoft.com and ns2.esoft.com, with the IP addresses of 199.45.143.14
  153. and 199.45.143.150, respectively, are authoritative for the domain
  154. esoft.com.
  155.  
  156.         Since these are the only two machines that can tell you
  157. what you need to know, if you can't reach them, you'll never be able
  158. to get domain name information from them.  Use the traceroute command
  159. to see how far you can make it.  The following example shows a break
  160. at the IP address 199.45.143.2 which probably means a router is down
  161. or has "forgotten" it's next hop:
  162.  
  163.  Cmd> tracroute ns1.esoft.com
  164.   1:  132.198.103.16    wat2-gw.uvm.edu. (2 ms) (2 ms) (2 ms)
  165.   2:  132.198.200.66    uvm-gw.uvm.edu. (2 ms) (2 ms) (2 ms)
  166.   3:  199.94.204.77     bbn-4.bbnplanet.net. (18 ms) (27 ms) (17 ms)
  167.   4:  199.94.205.1      bbn-1.bbnplanet.net. (19 ms) (20 ms) (202 ms)
  168.   5:  192.233.149.202   mit1-3.bbnplanet.net. (19 ms) (22 ms) (19 ms)
  169.   6:  192.233.33.11     cpe1-fddi-0.boston.mci.net. (27 ms) (40 ms) (32 ms)
  170.   7:  204.70.20.5       border1-hssi1-0.Boston.mci.net. (151 ms) (98 ms) (20 ms)
  171.   8:  204.70.2.33       core-fddi-0.Boston.mci.net. (24 ms) (29 ms) (66 ms)
  172.   9:  204.70.1.1        core-hssi-2.NewYork.mci.net. (48 ms) (39 ms) (35 ms)
  173.   10:  204.70.3.18      border2-fddi-0.NewYork.mci.net. (38 ms) (40 ms) (43 ms)
  174.   11:  204.70.45.6      sprint-nap.NewYork.mci.net. (39 ms) (43 ms) (53 ms)
  175.   12:  192.157.69.9     sl-pen-2-F4/0.sprintlink.net. (78 ms) (89 ms) (71 ms)
  176.   13:  144.228.10.38    sl-chi-3-H2/0-T3.sprintlink.net. (133 ms) (67 ms) (88 ms)
  177.   14:  144.228.50.15    sl-chi-15-F0/0.sprintlink.net. (122 ms) (87 ms) (115 ms)
  178.   15:  144.228.10.70    sl-kc-2-H3/0-T3.sprintlink.net. (78 ms) (99 ms) (87 ms)
  179.   16:  144.224.20.1     (100 ms) (134 ms) (135 ms)
  180.   17:  144.228.10.82    sl-che-2-H2/0-T3.sprintlink.net. (229 ms) (179 ms) *
  181.   18:  *** *** ***
  182.   Host Unreachable!
  183.  
  184.         On this route, the link appears to be broken after 144.228.10.82, so
  185. ns1.esoft.com can't be reached.
  186.  
  187.  
  188. Address Doesn't Exist
  189. ---------------------
  190.  
  191.         The final case is one in which the domain name simply doesn't
  192. exist.  You can tell this both from the resolver's response and looking
  193. at the cache.  For example, if you perform an nslookup on the domain
  194. thisdoesntexist.com, you will get back:
  195.  
  196.  Cmd> ns -rec thisdoesntexist.com
  197.  Authoritative response:
  198.  
  199.  Server reported No type "ANY" RR records for thisdoesntexist.com.
  200.  
  201.  Authority resource records:
  202.  com.    86400   IN      SOA     A.ROOT-SERVERS.NET.     HOSTMASTER.INTERNIC.NET.
  203.  1996031300 10800 900 604800 86400
  204.  
  205.         The root server reports back to the connected server that thedomain
  206. doesn't exist.  Additionally, if you look in the server's cache using the
  207. domain cache list command:
  208.  
  209.  Cmd> do ca li
  210.  thisdoesntexist.com.     86396   IN      ANY     [Negative Response Memory]
  211.  .
  212.  .
  213.  .
  214.  
  215.         You will see the [Negative Response Memory] noted, which means
  216. that the server was told by the root "I don't know who this domain is."
  217.  
  218.  
  219.  
  220. -----------------------------------------------------------------------------
  221.  
  222.  
  223.  
  224. - END -
  225.  
  226. IPAD0002.TXT
  227. Revised 3/96
  228.  
  229. Copyright (C) 1996 eSoft, Inc., All Rights Reserved.  Permission granted to
  230. distribute this file in its entirety, without modification, to any interested
  231. party.  Any other use requires the written permission of eSoft, Inc.
  232.  
  233. IMPORTANT:  The information herein is subject to change without notice. Please
  234. call or write to confirm factual information of importance to you or your
  235. organization.
  236.